不知不覺前 11 天已經做完了天氣推播、AI 日程簡報、新聞摘要、影片重點抓取、社群監控和補貨通知。但把這些流程全掛在背景跑幾天後，很快就會遇到現實世界的毒打：某個網站突然改版抓不到資料、外部 API 伺服器臨時當機、或是 AI 回傳格式不符合預期，整條工作流直接亮紅燈卡死。今天我們停下來整理這套系統，把最關鍵的例外錯誤處理（Error Handling）補齊，讓這群數位小幫手真正能穩定長跑。

最常踩雷的三大翻車現場
這幾天跑下來，流程會中斷通常逃不過這三種情況：第一是「網路逾時或對方伺服器噴錯」，特別是抓外部網頁或呼叫免費用量的 API 時，對方稍微抖一下就直接報錯；第二是「抓回來的資料格式變了」，原本預期該有標題或內文，結果傳回來的是空值或錯誤代碼，導致後續節點找不到欄位；第三是「AI 抽風或超出長度限制」，輸入太長或是觸發了安全審查，模型直接罷工。

第一招：開啟節點的 Continue On Fail
在 n8n 裡，預設只要任何一個節點失敗，整條流程就會立刻中斷並標記成紅色的失敗狀態。點開容易出狀況的節點（比如 HTTP Request 或 AI 節點），切換到右側的「Settings」設定分頁，把「Continue On Fail」開關打開。這個設定非常有用，它告訴系統：就算這個節點失手了也別停下，把錯誤資訊包成一個結果繼續往下傳，由後續的節點來決定要走備援方案還是安靜結束。

第二招：加上重試機制 Retry On Fail
很多網路連線錯誤純粹是對方伺服器那幾秒鐘塞車，如果直接判定失敗有點可惜。在同一個設定分頁裡，把「Retry On Fail」打勾，設定重試次數為兩到三次，並拉開每次重試的間隔時間（例如等待五秒再試一次）。光是加上這個彈性機制，就能搞定八成以上因為短暫網路波動引起的假警報。

第三招：建立專門收垃圾的 Error Trigger 流程
如果工作流真的徹底掛了，我們總不能每天手動進後台巡邏。n8n 有一個非常優雅的解法：開一張全新的空白畫布，放一個「Error Trigger」節點。只要系統裡任何一條工作流發生未捕捉的崩潰，這個錯誤觸發器就會被叫醒，把出事的流程名稱、壞在哪個節點、具體報錯訊息全抓出來，並立刻發一封緊急通知到我們的聊天軟體。這樣我們就能在第一時間知道系統壞了，點進後台直奔問題核心除錯，而不是過了好幾天才發現小幫手早就偷懶停擺。

把這些防護措施補齊後，整套自動化架構就從脆弱的玩具變成了皮實的工具。接下來我們將進入下一個大階段：玩轉外部主動發動的 Webhook，以及讓資料在雲端試算表與程式碼之間更自由地穿梭。明天先從讓外部隨傳隨到的 Webhook 開始聊起。